There is a continuing trend in the semiconductor industry towards higher circuit complexities within chips. These higher complexities are fueled by the progressive in reduction of feature sizes and the demand for ever more powerful microprocessors. As chip complexity increases the bus interfaces connecting chips to the outside world become more complicated. Additionally, many chips have an internal bus allowing communication between the various internal modules. It is important to ensure all the buses in a chip function correctly, as a single defect is almost certain to be encountered sometime during the operation of the chip. For example, one defect affecting some corner case of the bus protocol may result in a non-recoverable error. It is especially important to verify internal buses prior to the production of silicon. Internal buses are subject to all the problems of external buses with the additional constraint that they are by definition not visible from the outside. Therefore, the facilities for debugging them once the chip has been reduced to silicon are limited. Redesigns to fix problems are extremely costly, as they incur mask costs, fabrication costs, and delays in business.
Buses are inherently difficult to verify functionally because they usually contain a large number of signals. Many of these signals are bi-directional, so the possibility of a conflict due to poorly timed Bus Interface Units (BIUs) is probabilistically quite large. Counting all the address, data, and control signals, it is not unusual for a modern bus to have 100 or more bits of information. Considering the state space for the bus to be the Cartesian product of the states of the individual bits that compose it and the internal protocol state machines of all the agents that connect to it, it is obvious that trying to verify a bus by doing a complete state space search is untenable. Even viewing the address and data buses as representing a single state, the remaining state space is still impracticably large. It is therefore necessary to have a formal methodology for bus protocol verification that limits the testing to those states that are realizable within the protocol space.
One of the problems faced by the designer of a hardware chip or board is ensuring that devices attached to a bus conform to the bus protocol, where a bus is a set of signals that must be driven according to a specifiable protocol in order to achieve a desired result. Commonly, buses are used for transferring data, and the protocol specifies how read and write transactions may occur on the bus. The typical way a bus interface controller is verified is to create a behavioral model that exercises all supported transactions across the bus. If the operation completed without hanging the bus, it has passed the first level of test. A second level of test would then perform data compares of data written to a specific memory or address space. A third level of test would further include register read/write operations to check the integrity of the bus interface controller's registers. This strategy only checks to see if the bus is functional and does not verify compliance to the protocol.
Another method includes a bus monitor in the similation. The bus monitor deduces what transactions are taking place on the bus based on sampling signals at times of relevance to the protocol. These deduced transactions can then be compared against the intended ones to determine correctness at some level.
Many design solutions implement a graph-based representation, and make predictions based on the relations described therein. One alternative to using a graph-based representation for predictions is to do a cycle accurate prediction based on the test and compare the exact wave forms with those output by the simulation. These methods do not address issues such as noise detection, optional transitions, prediction of expected signal transitions, the modularity of the protocol, and operation outside of a strict cycle accurate approach. These methods lack the ability to check the correct behavior of other bus agents such as a bus arbiter or a pipe depth controller. Such agents may appear to function correctly but may in fact be designed differently from the specification. Additionally, the bus interface controller logic may deviate from specification while appearing to function properly in most cases. If such misbehavior is not flagged, the unintended logic feature goes undetected in design. Other methods use prediction where the bus interface controller is verified by predicting register results or data values at memory address locations. The results are predicted based on the test program to be executed. These methods are known as data prediction and data integrity methods.
A method referred to as resilient bus system has the receiving bus interface unit check the validity of certain pertinent signals. If any one of the signals is not valid the receiving bus unit rejects the request. The resilient bus system method does not verify the correct behavior of the rejection logic nor does it identify the source of the invalid bus signals.
Verification methods typically lack a way to verify whether the bus master device correctly requested a read or write as indicated by the test program. For example, if the test program asked for a read but the master requested a write, most verification programs would not detect this inconsistency. Additionally, if the master correctly asks for a read but performs a non-burst instead of an expected burst operation, these methods would not detect this inconsistency either.
It is desirable to have a bus verification method that is applicable to many different buses and is able to predict future transitions. Additionally, such a method should not employ strict cycle accuracy but be able to allow for implementation-dependent variances in transition times where allowed by protocol. It is also critical that a verification program identify noise on the specifically, unpredicted transitions. Ideally, a verification method would be modular to comprehend the complexities of a variety of buses.
The present invention offers a method of verifying bus protocol conformance employing a prediction scheme in a second stage correctness evaluator. This methodology provides a way to detect noise on a bus occurring at times other than when the protocol specifies the signal should be sampled, to handle all contingencies in a consistent manner, to determine the correct coverage information, and reduce the complexity of bus monitoring. The present invention employs a modular approach to bus protocol verification.